เพื่อน ๆ ที่เขียนโปรแกรมด้วย Java หลาย ๆ คนอาจจะยังไม่รู้จักว่า JVM นั้นมันคืออะไร... ทำงานอย่างไร...
.
วันนี้แอดจะมาสรุปวิธีการทำงานของ JVM ให้เพื่อน ๆ พอที่จะเห็นภาพกัน หาพร้อมแล้วไปอ่านกันนนน
.
🔹 JVM (Java Virtual Machine) - เป็นเอ็นจิ้นที่จัดเตรียมสภาพแวดล้อมเพื่อรันโค้ด Java ซึ่ง JVM มีหน้าที่รับผิดชอบในการแปลง Bytecode เป็นรหัสเฉพาะเครื่อง ซึ่งเจ้า JVM นี้จะสามารถติดตั้งได้บนทุก Platform ไม่ว่าจะเป็น Unix, Linux หรือ Windows
.
⚙️ วิธีการทำงานของ JVM แบ่งได้ดังนี้
🌟 Class Loader Subsystem
เป็นส่วนที่ใช้จัดการ Class Loader Subsystem โดยจะอ่านไฟล์ .class และสร้างเป็น Bytecode บันทึกไว้ใน Method Area จากนั้นจะสร้าง Object เพื่อเป็นตัวแทนไฟล์ไว้ใน Heap Memory
.
🌟 Runtime Data Area (JVM Memory)
ส่วนนี้จะเป็นการจัดสรรพื้นที่ของ Memory ให้เหมาะสม เพื่อนำไปใช้งานในแต่ละส่วน ได้แก่ Method Area , Heap Area, Stack Area, PC Register, Native Method Stack นั่นเอง
.
🌟 Execution Engine
เป็นส่วนที่ใช้ควบคุมกระบวนการทำงานต่าง ๆ ซึ่ง Bytecode ที่อยู่ใน Runtime Data Area จะถูกประมวลผลด้วย Execution Engine โดยจะอ่าน Bytecode และประมวลผลทีละบรรทัด
.
🌟 Native Method Interface
เป็น Interface ที่ใช้โต้ตอบกับ Native Method Library ทำให้ JVM สามารถเรียกใช้งาน C/C++ library ได้นั่นเอง
🌟 Native Method Library
เป็นที่รวบรวม Native Library ที่จำเป็นต่อการใช้งานใน Native Method Interface นั่นเอง
.
จบกันไปแล้วววว! หากใครมีอะไรเพิ่มเติม สามารถคอมเมนต์พูดคุยกันได้เลยน้าาา และหวังว่าจะเป็นประโยชน์กับเพื่อน ๆ นะคร้าบบบบ 🥰
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
stack heap 在 Re: [問題] stack vs heap sizes - 精華區C_and_CPP - 批踢踢 ... 的推薦與評價
我最近剛好又須要探討這個問題。
其實我一直對max stack size遠小於max heap size感到疑惑。
沒道理，automatic variables速度比dynamic variables快，
compiler要限制max stack size遠小於max heap size。
雖然之前Ebergies大有給個理由，但我一直覺得怪怪的，
在最後文章會有我的論點。
所以我又上google去找原因。
我發現真的有人說[1]"能用stack就用stack。不能用stack，才用heap。"
"In C++ use stack objects where you can, use heap objects when you have
to," said Peter van Merkerk.
"To summarize, use automatic storage whenever you can and dynamic
storage only when you must," said Tom.
但這並沒有解決我所有疑惑：為什麼max stack size那麼小？
max stack size那麼小，很容易就用光了。
後來我就去查Visual C++ max stack size是多少，但MSDN沒說多少，只說有上限[2]。
後來我只好自己去試。我發現我在Visual C++ 2010 Express的/stack設定
加了好多位數，都可以compile/link。
加到後來我驚覺一件事：Visucal C++早就可以叫很大的stack size。
後來我換成Visual C++ 2008 Express SP1，也是可以叫很大的stack size，
不是一般謠傳的16 MB[3]、32MB那麼小。
我的OS是Win 7 32-bit。
Visual C++ 2008的total automatic space上限是2GB，超過2GB會compile失敗。
我目前試出stack size可以到1.9G：
不過上圖一的那個"Memory (Priva..."其實只算physical memory的使用量，
要叫出phy+virtual memory，可以View/Select Columns.../Memory - Commit Size
※ 引述《zxvc (修行)》之銘言：
: 標題: [問題] stack v.s. heap sizes
: 時間: Sat Sep 12 20:14:48 2009
:
: 在Windows上stack最大可以設到32MB，
: heap卻可以設定到2GB。
:
: 請問為何這兩個限制大小差那麼多？
: 靜態變數(在stack)不是效能比較好嗎！？
: 為什麼需要配置大量空間不建議配置在stack？
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 140.115.221.79
: → suhorng:靜態變數!? 09/12 20:54
: → zxvc:應該說"靜態記憶體配置的變數"。 09/12 21:08
: 推 bobhsiao:stack是給local var用的, 通常幾十KB就夠了 09/12 22:12
: → bobhsiao:heap是給malloc/new用的, 使用量視AP而定 09/12 22:13
: 推 final01:heap可動態釋放!不過stack效能較好到是事實巴 09/12 23:06
: 推 Ebergies:這是邏輯上的思考, 通常 stack 是用來存取 function 內 09/12 23:15
: → Ebergies:的變數, 若 function 內的 local var 過大, 那麼這個 09/12 23:15
: → Ebergies:function 勢必不夠靈活, 光 recursive 沒幾次再大的 09/12 23:16
: → Ebergies:stack 也不夠用, 而這類超大空間的配置就使用上也大多 09/12 23:17
: → Ebergies:只需要配置很少的次數, 因此放在 heap 是合理且好的作法 09/12 23:17
不好意思，這樣有個假設，
就是所有漂亮的程式碼都不會是"遞迴且有很大的local variables"。
請問這能證出來嗎！？如果不能，這種coding style未必不好。
就算可能某些遞迴情形下，這些variables真的太大了，
難道"dynamic variables"就能解決這問題嗎？
如果max stack size可以跟max heap size一樣大(事實上stack真得可以很大)，
heap的1MB會等於stack的1GB嗎？
既然不會，沒道理"遞迴且有很大的variables，用stack不夠，用heap會夠！？"
又stack不一定是要用在遞迴，
比如我想在main function用到一個很大的local variable。
所以我認為heap的好處不是在因為function不能遞迴很多次，
是在於它能動態產生、釋放記憶體。
: → zxvc:謝謝樓上。 09/14 20:16
References：
[1] https://www.velocityreviews.com/forums/t278261-stack-vs-heap.html
[2] https://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx
[3] https://bluecat.csie.net/2009/10/28/3924/
--
信佛的人要知道：佛絕不會說謊。但請把握時光。
法滅盡經：
https://www.cbeta.org/result/normal/T12/0396_001.htm
共勉之。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.73.148
※ 編輯: zxvc 來自: 140.115.73.148 (08/30 12:39)
... <看更多>